ESPRES: Easy Scheduling and Prioritization for SDN

Network state is always in flux. Due to traffic engineering, topology changes, policy updates, VM migrations, etc., today’s networks undergo a variety of large updates that concurrently affect many switches. Transitioning between network states can be a source of instability, leading to outages, disruptions and security vulnerabilities. Consistent network updates [7] introduces a mechanism that guarantees to preserve well defined behaviors when transitioning between states. However, a major problem for this technique is the update performance, that is, the time it takes to install a network state update onto the data-plane—the current generation of OpenFlow switches can install flows with rate as low as 40 rules/second [2].1 Even moderate-sized updates can take several seconds, during which operators are in the dark about how badly links could be congested. [5] Therefore it is desirable to complete updates quickly. However, we note that the lowest bound of the total time to complete the update is determined by the switch that is last to complete. We observe that a large network update may consist of a set of sub-updates that are independent and can be installed in parallel in any order. Each sub-update comprises a list of rule modification commands across multiple switches along with an associated dependency graph between commands, as defined in [6]. Our insight is that it is possible to exploit this independence to improve the update performance by carefully managing the scheduling of deciding which sub-update to install in which order and, within each sub-update, which commands to enqueue at each switch. We can define the update performance to optimize for various objectives, such as: Finishing sub-updates quickly. While the overall network update time is dictated by the slowest switch, we can increase the update efficiency by finishing particular sub-updates soon after the update starts. This is especially important for consistent updates [7] since traffic is processed according to a subupdate only when the corresponding two-phase commit ends. Minimizing flow table overhead. Besides performance, an important problem is the rule-space overhead due to the extra number of rules that must be kept at the switches to implement the update. Like others [3, 6], we observe that there is a tradeoff between consistency, update speed and number of rules installed at a switch during an update. However, if an update consists of many independent rule commands, a scheduler can reorder the modifications to reduce the rule overhead during an update without impacting the total update time, for example by